[Report][AWS Summit Online ASEAN RE:CAP 2020]Hiệu quả từ hỗn loạn: Làm rõ hoạt động trong hệ thống phân phối

Ngày 29/09/2020 vừa rồi đã diễn ra sự kiện AWS Summit Online ASEAN RE:CAP. Link sự kiện: https://live.awsevents.com/ASEANSummitreCap/

Chủ để của session lần này là "Các mẫu kiến trúc: Xử lý luồng không cần máy chủ ở quy mô" Diễn giả: Arthi Jaganathan, Solutions Architect, Amazon Web Services

Khi tổ chức sử dụng cấu trúc Microservices, hệ thống phân phối có thể mang đến những thử thách cho nhóm của bạn vì đã quen với giải pháp monolithic. Phiên thảo luận này sẽ giới thiệu công cụ và kỹ thuật cho việc ghi nhận và giám sát môi trường phân phối. Và chương trình cũng hướng dẫn cho bạn cách ứng dụng giải pháp để đưa ra những thông tin hữu ích cho ứng dụng của bạn để cải thiện hoạt động hiệu quả nhất.

1. Hệ thống phân tán

Khi các công ty đang tìm cách để trở nên ngày càng linh hoạt hơn, họ đang phát triển các phương pháp xây dựng ứng dụng hiện đại, một trong những yếu tố của các ứng dụng hiện đại rất phổ biến hiện nay là mô hình kiến trúc Microservice. Các hệ thống phân tán như Microservices đặt ra thách thức mới cho các team đã quen với ứng dụng nguyên khối. Trong session này chúng ta sẽ xem xét một số công cụ và kĩ thuật để có được cái nhìn chi tiết vào các hệ thống phân tán và đồng thời cải thiện hiệu quả hoạt động của hệ thống của bạn.

Cách Leslie Lamport, American computer scientist định nghĩa Hệ thống phân tán như sau: "Một hệ thống phân tán là một hệ thống mà lỗi sảy ra trên một máy tính bạn không hề biết nó tồn tại có thể khiến máy tính của bạn không dùng được". Điểm chủ chốt của định nghĩa này là các hệ thống phân tán có mô hình lỗi phức tạp và chúng ta sẽ trở lại với điểm này trong những phần tiếp theo.

Bạn có thể phân loại các hệ thống phân tán dựa trên các ràng buộc về thời gian thực. Một cụm xử lý dữ liệu lớn hàng loạt cũng là một hệ thống phân tán. Nhưng trọng tâm của session hôm nay chỉ là các hệ thống thời gian thực, còn được gọi là "Dịch vụ theo kiểu yêu cầu - trả lời". Một ví dụ điển hình là một người dùng truy cập trang web của bạn tạo một lời gọi RESTFUL API tới hệ thống back-end và chờ phản hồi trong thời gian thực.

Vậy chính thức thì các thách thức với hệ thống phân tán là gì? Để trả lời câu hỏi đó hãy cùng xem 1 luồng yêu cầu - trả lời thông qua mạng điển hình trông như thế nào. Đây là một kiến trúc máy chủ - máy khách nơi bạn có một máy khách liên lạc với máy chủ qua mạng. máy khách gửi một tin nhắn lên mạng, mạng chuyển tin nhắn này cho máy chủ. Máy chủ khả năng sẽ thực hiện xác thực trước khi cập nhật trạng thái của mình rồi gửi tin nhắn trả lời. Tin nhắn này được chuyển đến máy khách. Ở đây nó cũng thực hiện việc cập nhật, xác thực và cập nhật trạng thái của mình. Vậy có 8 bước chỉ trong 1 luồng yêu cầu trả lời.

Việc này dẫn tới một số thách thức đặc thù:

• Có thể có nhiều biến thể của lỗi
• Xử lý các hoạt động mạng không dự đoán trước được
• Lỗi phân tán thường tiềm ẩn
• Các lỗi phân tán lây lan rất nhanh trong hệ thống

2. Cách giải quyết các thách thức của hệ thống phân tán

Thông qua khả năng quan sát (Observability)

Khả năng quan sát là mức độ mà bạn có thể suy ra các trạng thái bên trong của một hệ thống từ thông tin thông tin về các dữ liệu đầu ra bên ngoài của nó. Khả năng quan sát và kiểm soát của một hệ thống tỉ lệ thuận với nhau.

Khả năng quan sát có 3 trụ cột chính:

• Số liệu (Metrics) là tập hợp các dữ liệu theo thời gian, thường được tổng hợp qua một khung thời gian nhất định
• Logs là chuối các bản ghi chỉ được phép nối thêm, và cũng được sắp xếp theo thứ tự thời gian.
• Truy vết (Traces) là một loại logs chuyên biệt cho phép bạn quan sát luồng xử lý của yêu cầu trên hệ thống. của bạn.

Trên AWS bạn có thể sử dụng Amazon Cloudwatch và AWS X-Ray cho mỗi trụ cột này

Có 4 bước chính để hiện thực hoá cho khả năng quan sát trên hệ thống của bạn

• Bạn bắt đầu với việc thu thập dữ liệu.
• Sau khi có dữ liệu bạn sẽ cần xem xét dữ liệu
• Cấu hình các báo động để nhận được thông báo mỗi khi có sai lệch so với định mức và để bạn có thể hành động dựa theo đó
• Và cuối cùng bạn cần phân tích dữ liệu để có thể khắc phục được sự cố

Thông qua số liệu và logs (Metrics and Logs)

• Ở dưới cùng của lược đồ chúng ta có Đo đạc từ xa cấp hệ thống (System-Level Telemetry). cái này chỉ là các số liệu cấp cơ sở hạ tầng giữa CPU, RAM hoặc thông lượng mạng. Đây là những điều quan trọng cần theo dõi để đáp ứng các mục tiêu về độ tin cậy của trang web của bạn.
• Ở cấp độ tiếp theo chúng ta có Các số liệu ở cấp độ nghiệp vụ (Business-Level Metrics). Những số liệu này sẽ phụ thuộc ứng dụng cụ thể của bạn. Ví dụ như thời gian tải trang hoặc thời gian tải tác vụ
• Mục tiêu cuối cùng là để Hiểu sâu hơn về những trải nghiệm bạn đang cung cấp cho khách hàng đầu cuối của mình (Business Insight). Điều quan trọng là quan sát các số liệu cho phép bạn làm được điều đó. Ví dụ ở đây có thể là cảm tình của khách hàng hoặc SLAs

Một khi bạn biết những gì cần đo đạc, bước tiếp theo là thu thập dữ liệu. Khi nói đến đo đạc từ xa ở cấp hệ thống, trên AWS, tất cả các ứng dụng đều được tích hợp sẵn với Amazon Cloudwatch

Số liệu cho bạn biết rằng đã có sự cố xảy ra trong hệ thống, nhưng bạn cần Logs để tìm hiểu và khắc phục sự cố. Cách phổ biến nhất để thu thập Logs là có 1 trình nền chạy trên máy chủ của bạn. Và tiến trình này sẽ định kì thu thập Logs và đẩy chúng đi. Trên AWS bạn có thể sử dụng Amazon Cloudwatch Log Agent. Tuy nhiên cũng có nhiều trình thu thập Logs mã nguồn mở như Logstash, Fluentd, Graylog,...

Phân tích Logs:

• Khi nói tới phân tích Logs, Cloudwatch Logs Insights là 1 dịch vụ tương tác cho phép bạn chạy truy vấn giữa nhiều nhóm Cloudwatch Logs khác nhau.
• Nếu bạn sử dụng S3 để lưu trữ Logs của mình, Amazon Athena là một công cụ truy vấn tương tác dựa trên SQL để phân tích Logs
• ElasticSearch cũng là một lựa chọn phổ biến để phân tích Logs

Truy vết (Traces)

• Logs truy vết chạy trong phạm vi yêu cầu hoặc dòng chảy. Nghĩa là về cơ bản, nó cho phép bạn lần theo đường của một yêu cầu cụ thể đi qua hệ thống
• Logs truy vết có số lượng có thể có rất lớn, là một cách tuyệt vời để xác định mối quan hệ nhân quả trong hệ thống của bạn

Trên AWS, bạn có thể sử dụng AWS X-Ray để truy vết

• Phía bên trái slide bạn có 1 môi trường dựa trên EC2. Tại đây bạn sẽ thiết lập X-Ray Agent như một tiến trình nền, sau đó sử dụng X-Ray SDK trong ứng dụng của mình. Tiến trình nền mặc định tìm lưu lượng UDP trên cổng 2000.
• X-Ray SDK sau đó sẽ gửi các Logs truy vết tới tiến trình SDK. Tiến trình này sau đó sử dụng thông tin xác thực IAM để đẩy các dữ liệu này ra dịch vụ X-Ray.
• Bạn có thể sử dụng hồ sở EC2 để cung cấp thông tin xác thức IAM cho Agent
• Ở phía bên tay phải chúng ta có 1 ví dụ về môi trường tại chỗ, thực sự hoạt động của nó cũng khá giống với môi trường EC2. Bạn chỉ cần đảm bảo cung cấp đúng thông tin xác thực cho Agent để truy cập dịch vụ X-Ray
• Nếu bạn sử dụng các container trong chế độ khởi chạy EC2, bạn có thể chạy X-Ray agent dưới dạng bộ tiến trình nền. Đối với chế độ Fargate, bạn chỉ cần thiết lập nó như một circle

3. Demo

Mô hình kiến trúc ứng dụng bán lẻ dựa trên Microservice:

• Người dùng sẽ xác thực với Amazon Cognito trước khi truy cập vào 1 trang web tĩnh được đặt trên S3.
• Để đơn giản hoá sơ đồ này nên đã loại ra S3 và Cloudfront CDN
• Bất kể thành phần động nào của trang web đều được thực thi bởi AppSync, một GraphQL API được quản lý bởi AWS
• Tất cả thông tin liên quan đến người dùng ví dụ như phiên làm việc đều được xử lý bới dịch vụ người dùng, phần này được xây dựng với Amazon API Gateway và Lambda  Application Load Balancer
• Cuối cùng chúng ta có 1 dịch vụ báo cáo. Dịch vụ này xử lý Steams đơn hàng và xuất bản ra 1 số báo cáo
• Cũng có 1 trình tạo tải tạo trên Fargate không được hiển thị trên sơ đồ này

Trong Demo chúng ta sẽ đi qua 4 điểm quan trọng:

• Trích xuất các số liệu tuỳ chỉnh bằng cách sử dụng Embedded Metric Format và Logs Insights
• Nhận báo động về hệ thống với các ngưỡng động với CloudWatch Anomaly Detection
• Trực quan hoá hiệu suất dịch vụ bằng cách sử dụng Cloudwatch ServiceLens
• Mô phỏng khắc phục sự cố bằng việc phân tích X-Ray

Phần Demo khá dài và chi tiết, nên nếu bạn thấy thú vị và muốn tìm hiểu thêm.. Hay truy cập đường link của sự kiện và tìm video của session "Hiệu quả từ hỗn loạn: Làm rõ hoạt động trong hệ thống phân phối"

Cảm ơn các bạn đã theo dõi blog. Xin chào và hẹn gặp lại!